REMARKS 

Claims 8, 19, 22, 23, 38, 42, 43, 48 and 51 have been canceled. New claim 55 has been 
added. Claims 1-7, 9-18, 20, 21, 24-37, 39-41, 44-47, 49, 50 and 52-55 are now pending in this 
application. 

Rejection under 35 USC §101 

Claims 25-36 and 52-54 are rejected in that the terms "trusted party" and "presenter" have 
been interpreted to include human beings. Claims 25 and 52 have been amended to recite a 
"presenter computer" (Figure 1, 708 and page 7, lines 13-14), a "trusted party computer" (access 
control server 712 of trusted party 710) and an "acceptor computer" (718, page 10, line 7). 
Therefore, it is requested that this rejection be withdrawn. 

Rejection under 35 USC §112, first paragraph 

The Office action has suggested that the limitation of a "trusted party computer" and the 
various method steps performed by this computer are not disclosed in the specification. Figure 1 
shows a trusted party that includes an access control server (ACS) 712. Page 7, line 24 describes 
the ACS as a computer system. Lines 14-26 of this page also describe the method steps 
performed by this trusted party computer. In addition, Figure 1 shows messages 2, 3 and 6-8 
passing back and forth between the access control server computer and other computers in the 
system. Page 10, line 22 through page 15, line 19 discuss the method steps being performed by 
the access control server computer (which is included within the trusted party). 

Applicant notes that the limitation of "in real time" is supported in the provisional 
application filed September 10, 2002. Support for the inventive technique being performed in 
"real time" can be found at page 15 (final paragraph), page 16 (first full paragraph), and page 22 
(first and third paragraphs). Applicant therefore requests that these rejections be withdrawn. 

Rejection under 35 USC §112, second paragraph 

The Office action suggests that it is unclear whether the claims in the application are 
directed toward an enrollment process or an online transaction. The examiner is correct to 
interpret the method claims to include both the enrollment process and the authentication of the 
online transaction. Claims 1 and 37 require that the first three steps occur during an enrollment 
process; Applicant has amended these claims require that the fourth step occur " during said on- 
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line transaction after said enrollment process " to make clear the difference between the 
enrollment process and the online transaction. One of skill in the art upon reading the 
specification will understand that the subsequent steps also occur during the online transaction. 
The preamble of claims 1 and 37 do recite a method of either validating or providing profile data 
during an online transaction (and that is what the method does), even though the method does 
include preliminary steps involving an enrollment process. Applicant submits that this wording 
of the preamble does not render these claims confusing, although Applicant is willing to delete 
the phrase "during an online transaction" from the preamble if necessary. 

Claims 25 and 52 are system claims that clearly describe which limitations are present 
during an enrollment process and which limitations are present during the online transaction. 
There is no preamble similar to the method claims and Applicant submits that these system 
claims are not confusing and requests that the rejection be withdrawn. 

Rejection under 35 USC §102 

The Office action has rejected the claims under § 102(e) as being anticipated by 
Dominguez et al. {Dominguez), U.S. publication No. 2004/0059688, application No. 10/660,263. 
But, this reference is nothing more than the publication of the present application. A reference 
cannot be cited as prior art against itself. It is requested that this rejection be withdrawn. 

Rejection under 35 USC §103 

The Office action has rejected claims 1 and 25 under §103 as being obvious in view of 
Carrott et al. (Carrott), Tsuei et al. (Tsuei) and Sipman et al. {Sipman). Although the 
Examiner' s arguments have been carefully considered, Applicant respectfully traverses this 
rejection as explained below. 

Claim 1 requires fourth and fifth steps of receiving and comparing submitted profile data 
against profile data already stored by the trusted party. This submitted profile data has been 
received from the acceptor (which in turn received it from the presenter) which is trying to verify 
if this submitted profile data is correct. The sixth and seventh steps require receiving and 
authenticating the authentication data from the presenter. A valid authentication would tend to 
indicate that the true presenter has submitted the submitted profile data. Finally, the eighth step 
requires that the trusted party validate the submitted profile data using these results. In other 
words, the trusted party validates that the submitted profile data matches the stored profile data 
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and that the submitted authentication data matches with the authentication data. These steps 
occur during the online transaction and are closely related. 

The Office action alleges that the fourth and fifth steps are disclosed in Carrott and that 
the sixth and seventh steps are disclosed in Tsuei. The action then alleges that the eighth step is 
disclosed in Sipman. Because these fourths through eighth steps are closely related, trying to 
find all of them in three different references yields unworkable results. 

Firstly, even though Carrott might disclose in column 2 that customer information is 
given to a merchant in the transaction and then forwarded to a financial institution, that financial 
institution is not authenticating the customer during that same transaction. The Office action 
relies upon Tsuei as disclosing authentication in general during a transaction. But, these fourth 
through seventh steps require that authentication of the presenter {e.g., the customer) occur 
during the same transaction in which the submitted profile data is received and compared. Tsuei 
does not disclose any authentication of the customer during the same transaction in which 
submitted profile data of the customer is received and compared. 

Secondly, the Office action alleges at page 9 that Sipman discloses the eighth step of: 

validating, by said trusted party, said submitted profile data using results 
of said comparing and results of said authenticating. 

Thus, in order to validate the submitted profile that the acceptor has received from the 
presenter, this step requires not only that the trusted party make a determination that the 
submitted profile data is the same as the profile data that is stored, but also that the submitted 
authentication data from the presenter is the same as the authentication data established during 
the enrollment process. Sipman does not disclose this step and its requirements. 

Sipman does show in Figure 4 that a transaction server holds a profile of a first party 33 
and a profile of a second party 34. But, importantly, a profile of one party is never divulged to 
the other party. The profile of the first party is stored by the transaction server and is used by the 
transaction server to authenticate the first party during a transaction (column 7, lines 16-20). By 
contrast, the eighth step of claim 1 requires that the trusted party validate the submitted profile 
using the results of the fifth comparing step; in other words, the trusted party must validate that 
the submitted profile data is the same as the profile data it has stored. Thus, the trusted party 
validates that the submitted profile data received from the acceptor (having been previously 
received from the presenter during the transaction) is the same as the profile data that the 



16 



presenter sent to the trusted party during enrollment. Assuming for the sake of argument that the 
first party of Sipman is analogous to the presenter and that the second party is analogous to the 
acceptor, Sipman is not comparing stored profile data of the first party with submitted profile 
data from the second party. Sipman is comparing stored profile data of the first party with 
submitted profile data from the first party . In other words, the first party sends its own profile 
data to the transaction server to be compared against its own profile data which had previously 
been stored. The first party of Sipman does not send its profile data to the second party, so that 
the second party can then submit the profile data to the transaction server to be compared against 
the stored profile data of the first party. The eighth step of claim 1 requires that the submitted 
profile data is validated by comparing stored profile data of the presenter with submitted profile 
data that has come from the acceptor . 

For this reason, it is requested that rejection of claim 1 be withdrawn. Claim 25 includes 
similar limitations and is believed patentable for the same reasons. 

Rejection under 35 USC §103 

The Office action has rejected claims 37 and 52 under §103 as being obvious in view of 
Carrott et al. (Carroti), Tsuei et al. (Tsuei) and Sipman et al. (Sipman). Although the 
Examiner's arguments have been carefully considered, Applicant respectfully traverses this 
rejection as explained below. 

Claim 37, as pointed out in the previous reply, requires in the fourth step that the acceptor 
ask the trusted party to provide the profile data of the presenter, and in the seventh step that the 
trusted party provide this profile data to the acceptor. The Office action has cited Sipman. But, 
as explained above, Sipman in Figure 4 only discloses that the transaction server holds the profile 
of the first party and the profile of the second party. The transaction server does not give the 
profile of one party to the other party. In particular, the second party is not asking the transaction 
server to provide the profile 33 of the first party, and the transaction server does not provide the 
profile 33 of the first party to the second party. The first party might fill in a form, but this is not 
a first-party profile that the transaction server provides to the second party. 

For this reason, it is requested that rejection of claim 37 be withdrawn. Claim 52 
includes similar limitations and is believed patentable for the same reasons. 
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Dependent Claims 



Since the dependent claims depend from the independent claims, it is respectfully 
submitted that they are each patentable over the art of record for at least the same reasons as set 
forth above with respect to the independent claims. Further, each of the dependent claims 
require additional features that when considered in light of the claimed combination further 
distinguish the claimed invention from the art of record. 

For example, claims 9, 29, 44 and 55 require a program identity number that allows the 
trusted party to match up the submitted profile data from the acceptor with the stored profile data 
originally submitted by the presenter during enrollment. The Office action has cited Tsuei, but 
this reference does not disclose that a program identity number is correlated with profile data and 
authentication data received by the trusted party computer, nor that the program identity number 
is received by the trusted party from the acceptor during the online transaction. It is requested 
that the rejection of these claims be withdrawn. 

Reconsideration of this application and issuance of a Notice of Allowance at an early date 
are respectfully requested. If the Examiner believes a telephone conference would in any way 
expedite prosecution, please do not hesitate to telephone the undersigned at (612) 252-3330. 

Respectfully submitted, 
Beyer Law Group llp 

/Jonathan O. Scott/ 

Jonathan O. Scott 
Registration No. 39,364 

Beyer Law Group llp 
P.O. Box 1687 
Cupertino, CA 95015-1687 

Telephone: (612) 252-3330 
Facsimile: (612) 825-6304 
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